-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rule: directory-package-mismatch
#1024
Conversation
([via Regal](https://docs.styra.com/regal/language-server#code-completions)) suggesting the package path | ||
`authorization.rbac.roles`. | ||
|
||
![package path auto-completion](../../assets/rules/pkg_name_completion.png) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this will need to similar to this: https://github.com/StyraInc/docs/blob/main/docs/regal/language-server.md?plain=1#L26-L28
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ugh :/ But thanks! Fixed in last push.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! It's an opinion, but opinions like these are going to really help new Rego users in particular here.
Time to ruffle some feathers! Or move to the `custom` category, I haven't decided yet 😆 Either way, while this rule can certainly feel disruptive, larger policy projects *should* have a uniform structure. Some notes on the implementation: - Does not complain if a single file is provided, i.e. when there is no path except for the file. So `regal lint p.rego` will not result in a violation. - Allows `_test` packages to either reside in the same directory as the package they test (this is the default) or to be kept in a separate directory matching the package exactly (optional). Other than the rule implementation itself, this naturally required that we we restructured all of our own directories to follow this convention. I wasn't too sure about it at first, but the result definitely seems both clean and correct, so I think we're right about this. Also helped correct a few typos in names! Fixes #1007 Signed-off-by: Anders Eknert <[email protected]>
f11a556
to
5cc9f70
Compare
Time to ruffle some feathers! Or move to the `custom` category, I haven't decided yet 😆 Either way, while this rule can certainly feel disruptive, larger policy projects *should* have a uniform structure. Some notes on the implementation: - Does not complain if a single file is provided, i.e. when there is no path except for the file. So `regal lint p.rego` will not result in a violation. - Allows `_test` packages to either reside in the same directory as the package they test (this is the default) or to be kept in a separate directory matching the package exactly (optional). Other than the rule implementation itself, this naturally required that we we restructured all of our own directories to follow this convention. I wasn't too sure about it at first, but the result definitely seems both clean and correct, so I think we're right about this. Also helped correct a few typos in names! Fixes StyraInc#1007 Signed-off-by: Anders Eknert <[email protected]>
Time to ruffle some feathers! Or move to the
custom
category, I haven't decided yet 😆 Either way, while this rule can certainly feel disruptive, larger policy projects should have a uniform structure.Some notes on the implementation:
regal lint p.rego
will not result in a violation._test
packages to either reside in the same directory as the package they test (this is the default) or to be kept in a separate directory matching the package exactly (optional).Other than the rule implementation itself, this naturally required that we we restructured all of our own directories to follow this convention. I wasn't too sure about it at first, but the result definitely seems both clean and correct, so I think we're right about this. Also helped correct a few typos in names!
Fixes #1007